In automated magnetic tape drive “libraries”, typically the controller for the library communicates with the associated tape drives via a serial data interface for the purpose of detecting tape drive status and issuing certain commands and requests to the tape drives. The term “library” has a particular meaning in this context. Previously, a standalone tape drive was typically used to back up data stored in a computer. However, more recently tape drive “libraries” have become more widely used because of their greater capacity. A tape drive library (or “tape library”) includes several tape drives and a number of associated media storage slots. Magnetic tape media (tape cartridges) are stored in the media slots and are transferred to the tape drives typically by a robot as required for read/write operations.
One type of data available from a tape drive is so-called “log” or “logging” data. Log data typically provides an accounting of activity that the drive performed or experienced and can be useful in troubleshooting the drive. Special forms of log data are often referred to as “dumps” since the represent a dump of a large quantity of data stored at the tape drive at a particular time. Sometimes log and dump data can be very large amounts of data, but tape drives typically have a limited amount of storage resources in the tape library available to retain such data.
Further, other issues relate to this logging data. One is that the tape library controller has to determine when to retrieve the data from the individual tape drives, typically by polling (interrogating) the drives through the tape drive's serial data interface(s). It is to be appreciated that the tape drives are connected to the library controller via a data network of some type, which connects to each individual tape drive through its serial data interface. This often creates a delay from when useful logging information is available at the tape drive until it is retrieved. Sometimes this causes important logging information to be lost either because the library controller did not timely retrieve the log data or the drive itself did not have enough local resources (memory) available to store all the relevant log data or both. Another problem is that the amount of available logging data, especially in the case of a dump, may be excessive to retrieve it efficiently via the relatively slow serial data interface.
In the past, these problems have been addressed in one approach such that when the library controller decides to retrieve the log data from the individual tape drives, it issues a command such as “SCSI Read Buffer” (or equivalent) via a serial data protocol, such as ADI (Automation Drive Interface). Alternately, this command is issued via the host interface, such as Fibre Channel. For larger amounts of log data, such as a dump, typically a particular tape cartridge has to be mounted in a drive in order for the tape drive to write the data to the tape cartridge for purposes of logging and then the tape cartridge has to be transported elsewhere for analysis. Each of these approaches is slow and prone to the above-indicated efficiencies.
To put this another way, as the complexity of storage systems increases, identifying faults and improving performance of such systems has become more difficult. Manufacturers of data storage components, such as tape drives, usually provide information regarding the expected performance of the unit and if the user believes the actual performance of the system in use is not the same as the specified performance, he wants to determine causes of performance deficiencies. Typically in order to identify which components of the storage system may be responsible for sub par performance, the operator of the library runs particular software tools for diagnostic purposes. However use of such tools has drawbacks, such as again a particular tape cartridge has to be installed in a tape drive at the time when data is to be logged.